Keywords 

linear logic, blockchain, types, Curry-Howard 


ABSTRACT 

We present an interpretation of classical linear logic 
in terms of operations on the blockchain. 


Linear types can change the blockchain! 


L.G. Meredith 

CSO, Synereo 

greg@synereo.com 


1. BACKGROUND AND MOTIVATION 

Anyone who understands the current economic, socio¬ 
logical, and technological situation is likely to be very 
excited by what the blockchain technology promises. 
Anyone who has actually had to work with the blockchain 
in real situations with mission-critical exchanges on 
the line is very likely to be motivated to find a more 
scalable and reliable architecture for the blockchain. 
This paper takes a few key steps towards finding a way 
to explain and test a hypothesis that linear proofs pro¬ 
vide the basis for a much more scalable architecture 
for the blockchain. For background on what is meant 
here by linear proofs, [5] interprets them in terms of 
games, while [3] interprets them in terms of traditional 
computational calculi like the lambda calculus. 

A linear proof is a formal structure representing a 
proof of a formula in linear logic [6]. The Curry- 
Howard isomorphism m tells us that formulae are 
types (as in data types in a programming language), 
and that proofs are programs. This is a very broad 
and deep idea. In the 90’s, for example, Abramsky ex¬ 
tended it to proofs as processes [4] , which Wadler was 
only very recently able to realize as a correspondence 
between linear proofs and 7r-calculus processes |14 |. 

In this context it means that linear proofs provide a 
representation of both data (blocks) and program (ex¬ 
ecutable transactions) that gives several advantages 
over the current choices made by the blockchain. 

The blockchain is a great example of data that is also 
program; it’s a giant ledger spread out over the In¬ 
ternet, that’s made of a bunch of distributed, but 
interacting servers m- To become more scalable. 


and reliable, both ledger and servers will need certain 
characteristics of data/program that have to do with 
a property called compositionality. Scalability is al¬ 
ways all about being able to build composite systems 
from components. For example, if we can prove that 
sections of the blockchain can be safely isolated from 
other sections, for example, if all blocks necessary to 
prove that Alice has sufficient funds to send M btc 
to Betty, can be isolated from the blocks necessary to 
prove that Alfred has sufficient funds to send N btc to 
Bob, then Alice and Betty, and Alfred and Bob can 
safely work with projections of the blockchain, and 
thus complete their transactions, not only in isolation 
of each other, but without the onerous need to sync 
the entire blockchain. 

One analogy is the use of separation logic (a child of 
linear logic) |12j to prove things about the structure 
of the heap which can, in turn, be used to guarantee 
that two threads can operate at the same time safely. 
The blockchain is like the heap. The Alice - Betty and 
Alfred - Bob transactions are like the two threads. A 
proof that the heap is of the form Hi 0 H 2 together 
with a proof that Ti : Hi —>■ H'l, T 2 : H 2 —>■ H 2 
constitutes a proof that Ti 0 T 2 (thread Ti running 
concurrently with T 2 ) operate effectively in isolation 
and thus safely. Likewise, a proof that the blockchain 
is of the form Bi 0 B 2 (none of the transactions in Bi 
connect to addresses in B 2 and vice versa), together 
with a proof that AliceBetty : Bi ^ B'l (this txn uses 
only addresses in Bi), and Alfred Bob : B 2 —t B 2 (this 
txn uses only addresses in B 2 ) constitutes a proof that 
AliceBetty 0 AlfredBob can operate with isolated pro¬ 
jections of the blockchain. 

If the blockchain is built using the primitives of linear 
logic, it becomes easier and easier to construct these 
proofs, but also to construct the blockchain, itself, in 
terms of smaller blockchains. 


2. INTERPRETING LINEAR PROOFS 

AS OPERATIONS ON THE BLOCKCHAIN 

Here’s the most basic interpretation. 


h Iblkchnaddr : j 4 (g>... (g> A 

M 


is a statement that there are M A’s available at the ad¬ 
dress, Iblkchnaddr. A’s can be any resource, BTC’s, 
AMP’s, DogeCoin, etc. 


h txn 

M N 


is a statement that txn will generate N B’s if provided 
M A’s. 

Terminologically, we say that Iblkchnaddr is a witness 
or a proof of A (g)... 0 A, and similarly, that txn is a 
witness or proof ofA0...0A^B0...0B. Given 
two such proofs we can use the cut rule of linear logic 
to produce a proof 


h txnilblkchnaddr) : B iSi ■ ■ ■ <Si B 


where txn{lblkchnaddr) is a new address in the blockchain 
constructed from the information in txn together with 
Iblkchnaddr. This should look remarkably like func¬ 
tion application, because it is. 

Notice that now we can see, recursively, what a proof 
of a statement like h Iblkchnaddr : A ® ® A looks 

like. In most cases it will be a proof made from a pre¬ 
vious application of the cut rule. This tree of cuts will 
trace all the way back to some genesis block - which 
is the only other way to have a proof of a statement 
like h Iblkchnaddr : A 0 ... ® A. 

Now, where does the return address associated with 
txnilblkchnaddr) come from? To see this we have to 
look into the mechanics of ^ (called linear implication 
or, more affectionately, lollipop). 


A-oB = A^‘^B 

Linear implication is decomposed much like classical 
implication in terms of a negation (A^) and a disjunc¬ 
tive connective (A ^ B). It is literally an expression 
capturing the sentiment we need A to get B, or B 
comes with a cost of A. The use of a proof rule for 
these kinds of links looks like 


h r, Iblkchnaddr : A^, 2blkchnaddr : B 
h r, Iblkchnaddr ^ 2blkchnaddr : A^ ^ B 

where we snuck in the rest of the blockchain as T. As 
we saw above, A^ ^ B — A B; so, we can write 


h r, Iblkchnaddr : A^, 2blkchnaddr : B 
h r, Iblkchnaddr —o 2blkchnaddr -. A —« B 

Now we see that forming a txn comes with the require¬ 
ment to provide an address where A’s will be sent and 
an address where B’s will be received. To complete 
the picture, applying the cut rule will create the txn 
that links an address, say iblkchnaddr with an A in 
it, to Iblkchnaddr, resulting in h F, 2blkchnaddr : B. 
Expanding on these intuitions, we can see that the 
rules of classical linear logic correspond exactly to a 
specification of operations on the blockchain. 

2.1 Linear Sequents 

In more detail, a proof rule in linear logic is usually 
written in terms of a transformation. 


Si,S2,...,Sn 

S 

taking sequents Si,...,Sn to a sequent S, where a 
sequent is of the form 


h r, : Ai,. . . , tjv : Ajv 

A sequent is really just a statement about what is 
distributed where in an instance of the blockchain. 

• ti,... ,tN are either addresses or programs that 
take addresses as input; they constitute the ’’fo¬ 
cus” of the proof rule, or where the action is 
going to happen. 

• Ai,..., Ajv are (types built from) the different 
types of coin 

• r is the rest of the blockchain - it is necessary to 
establish the distribution of resources we see at 
ti,..., tN, but it’s not the focus of the operation 
of the proof rule. 

Putting it all together, a proof rule of the form 



ft 

ft 


is then a statement about how the blockchain in state 
Si goes to a blockchain in state ft. If you think about 
it, that’s just what we need to reason about transac¬ 
tions. In a transaction where Alice sends Betty N 
coin, we can think of the transaction as a rule that 
takes a blockchain in a state where Alice has N btc to 
a blockchain in a state where Betty has N btc. 

2.2 The Multiplicatives 

Linear logic, however, allows to build bigger blockchains 
from smaller ones, and manages the dependency and 
information flow so that everything remains consis¬ 
tent. Here’s an example. The proof rule for the tensor 
A® B looks like this 


h r, t : A, h A, u : B 
|-r,A,t®M:A(g>B 


It says that if you have one blockchain, \- V,t ■ A, 
and another completely independent blockchain, with 
a totally separate address space, h A, u : B, then you 
can make a new one 


|-r,A,t0M:A(g)B 


in which you just combine all the data of assignments 
of addresses to resources in G and H in one big blockchain, 
G, H, and you can make a kind of composite address 
(or program), t ® u, at which can be found the com¬ 
bined A® B resource. 

Now, comparison of the par [ A^ B ) rule, which es¬ 
tablishes transaction links, is even more illuminating. 


h r,t:A, u : B 
A^ B 


This rule insists that the transaction link, t ^ u, is 
made in the same piece of the blockchain, T. 

The piece of the puzzle that interprets commitment 
to and execution of transactions is the cut rule. If 
Iblkchnaddr —o 2blkchnaddr is a transaction waiting 
to happen, so to speak, txn{3blkchnaddr, Iblkchnaddr— 
o2blkchnaddr) is the commitment to carry out the txn 
against the blockchain. Likewise, cut-elimination, also 


called proof-normalization, which corresponds to com¬ 
putation, via Curry-Howard, constitutes the execution 
of the transaction on the blockchain that results in 
the assignment h L, 2blkchnaddr : B after execution. 
Someone familiar with functional programming might 
interpret 

txn{3blkchnaddr, Iblkchnaddr —o 2blkchnaddr) 
as 

apply {Iblkchnaddr ^ 2blkchnaddr, iblkchnaddr) 

making the correspondence to function application, 
and the correspondence between proof normalization 
and /3-reduction explicit. 

The fragment of linear logic that includes, A^, A®B, 
A^ B, A —o B, is called the multiplicative fragment 
of linear logic, or MLL. It talks about the basics of 
transactions, loading up addresses with resources and 
establishing dependencies between addresses, essen¬ 
tially recording transaction history. However, it does 
so in a way that keeps track of how the blockchain it¬ 
self is segmented. This allows us to determine things 
like how much of the blockchain do i have to see in 
order to safely conduct this transaction, or can i con¬ 
duct this transaction without needing visibility into 
that region of the blockchain. 


2.3 The Additives 

Linear logic also enjoys another fragment, called the 
additives. This aspect of the logic is all about condi¬ 
tionals and contingencies, this or that, but not both. 
The linear logic connective called ’with’, and denoted 
Aik B, collects options together into a menu for sub¬ 
sequent selection by interaction with choices indicated 
by the linear connective ’plus’, A -|- B. In symbols. 


while 


and 


h r,t : A 

,u : B 

h r, t & u 

■.AkB 

1- r,t 

: A 

h inl{t) : 

A + B 

h r,M 

: B 

h inr(u) : 

A + B 



If during a more complex transaction t &iu gets tied 
to inl{t'), via txn{t & u, then this will reduce 

to a transaction of the form On the other 

hand, txn{t & u, inr(u')) will reduce to a transaction 
of the form txn(u, u'). 

2.4 The Exponentials 

The fragment of linear logic that includes the mul¬ 
tiplicative and additive connectives is called MALL. 
The remaining connectives are called the exponentials, 

?A, and \A. They denote copyable, non-conserved re¬ 
sources. When we write h r,t :\A, we are saying that 
you can get as many A’s from the address (or program) 
t as you want. Thus, unlike currency, that address is 
linked to a copyable resource like a document, or a 
jpeg, or audio file, or ... that can be shared widely. 
When we write h L, t :?A, we are saying that you can 
put as many A’s into the address (or program) t as 
you want. You can think of it as a place to store A’s, 
or discard them. 

What’s critically important about the use of the ex¬ 
ponentials is that they mark resources that ought not 
to stay on the blockchain. They indicate content and 
content types that can be better served by a different 
kind of content delivery network. This is another im¬ 
portant function in helping with a scalable blockchain 
- use blockchain technology where it makes sense and 
use other means where it doesn’t. 

Taken all together, we have an interpretation of full 
classical linear logic in terms of operations on the 
blockchain. 

3. CONCLUSIONS AND FUTURE WORK 

We have developed a view of full classical linear logic 
in terms of operations against the blockchain. The 
view we have been developing not only extends to pro¬ 
vide a meaningful interpretation of full classical lin¬ 
ear logic to natural and intuitive operations on the 
blockchain, it also extends and expands how we think 
about the blockchain and what transactions on it are. 
Additionally, it provides guarantees, mathematical cer¬ 
tainties about the correctness of transactions struc¬ 
tured and executed this way. In particular, notice 
that we focused mostly on the connectives governing 
A’s and B’s (the resources to be found at addresses 
or programs). We didn’t really talk about the struc¬ 
ture of t’s and u’s. These provide us with a simple 
and intuitive syntax for transactions. Of equal impor¬ 
tance, these transactions are typed programs. When 
we write h T, t : A, we are not only saying something 
about the resources produced or manipulated by t, we 
are saying something about how t can be used, and in 
what blockchain context we can expect t to perform 
correctly. 

Understood this way, the blockchain interpretation 


gives new meaning and perspective on some theorems 
from the linear logic literature. In particular, it is well 
established that there is a natural notion of execution 
of t’s. That is, when thought of as programs, we know 
how to run them. When they are well typed, that is, 
if we have established \- t : A, then t is terminating. 
That’s a theorem from [3]. What this means for the 
blockchain is that proof terms and their linear con¬ 
nectives provide a scripting language for transactions 
that, on the one hand, provides termination for all well 
typed scripts, and on the other is highly expressive. 
Further, if it turns out that this scripting language 
is not expressive enough, then there is a natural ex¬ 
tension of proof terms via a correspondence between 
linear proof terms and vr-calculus processes that we 
mentioned at the top of these notes. 


proof term 

blockchain meaning 

address 

address 

t®u 

isolated concurrent transactions 

t^ u 

interacting or linked concurrent transactions 

t &iU 

menu of transaction options 

inl{t),inr{u) 

transaction option selection 

H 

copyable resource server 

U 

copyable resource storage 

txn{t, u) 

joined transactions 


This correspondence is not just useful for extending 
a scripting language for blockchain transactions. It 
turns out the rr-calculus the premier formalism for 
specifying, reasoning about, and executing protocols 
in distributed systems |10| [9] [2] n [7] 0. Since one 
of the real values of the blockchain is the fact that it is 
a distributed means to conduct transactions, the need 
to tie this formalism to one for specifying protocols in 
distributed systems is plain. 

3.1 Proof-of-work 

The glaring lacunae in this discussion is, of course, the 
relationship to proof-of-work. Consider the following 
example. Suppose Ci and C 2 are blockchains both of 
height N. 

Cl = Bin <— Bijv-i ■(—■■■ <r- Bio 

C 2 = B 2 N B 2 N -1 B 20 

We can define 


Ci®C2 = {Bin®B2n) ■<— {Bin-i®B2n-i) {Bio®B2o) 

Note that it is insufficient merely to guarantee for B® 

B' that all the transactions in B are isolated from the 
transactions in B'. The counterexample is 




Cl = Block{lAliceAddr lAllanAddr} 

<— Block{lBobAddr IBettyAddr} 

C 2 = Block{lBobAddr IBettyAddr} 

<— Block{lAliceAddr lAllanAddr} 

Clearly B\\ is isolated from B 2 i, and Bio is isolated 
from B 20 ; but, B 20 is not isolated from Bn, and Bio 
is not isolated from B 21 . As a result, the spends in 
the earlier blocks could impact the spends in the later 
blocks. 

Instead, the entire address space of Ci must be iso¬ 
lated from C 2 . In this case the network of servers, 
Ni , that maintain Ci can be safely combined with the 
network of servers, N 2 , that maintain C 2 , and we can 
safely define the composite chain as above. The proof- 
of-work protocol organizing N\ is completely separate 
from that in N 2 - They do not interact. Yet, it is safe 
to combine the chains using a glorified zip function. 
In this example, 

Cl = BI ock{l Alice Addr lAllanAddr} 

<— Block{2BobAddr HAlA- 2BettyAddr} 

C2 = Block{lBobAddr IBettyAddr} 

Block{2AliceAddr 2AllanAddr} 

The address spaces of these chains are completely iso¬ 
lated (often written addresses{Ci)#addresses{C 2 ) )■ 
We are free to calculate 

Cl ® C 2 = Block{l Alice Addr lAllanAddr} 

®Block{lBobAddr IBettyAddr} 

<— Block{2BobAddr 2BettyAddr} 

(g)Block{2AliceAddr 2AllanAddr} 

= Block{lAliceAddr lAllanAddr-, 

IBobAddr IBettyAddr} 

<— Block{2BobAddr 2BettyAddr 

; 2AliceAddr 2AllanAddr} 

The ordering of transactions provided by the two in¬ 
dependently executing proof-of-work protocols is com¬ 
bined in a completely safe. 

Note that there are at least two possible interpreta¬ 


tions of Cl * C2. One is that the requirement is to 
verify that addresses{Ci)#addresses{C 2 )- Another 
is to ensure this is the case by rewiring the transac¬ 
tions. Under this latter interpretation even the coun¬ 
terexample becomes safe 

Cl 0 C2 = Block{l Alice Addr lAllanAddr} 

iSiBlock{lBobAddr IBettyAddr} 

<— Block{lBobAddr HAlA QlBettyAddr} 
®Block{lAliceAddr llAllanAddr} 

= Block{01AliceAddr OlAllanAddr-, 

11 Bob Addr HAlA 11 Betty Addr} 
Block{01BobAddr OlBettyAddr-, 

llAliceAddr llAllanAddr} 

There is much more to be said, but that must be left 
to future work! 
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Discussion. ei —o e 2 is really just convenient syntac¬ 
tic sugar for e^ffe 2 , where is identity on addresses, 
but changes the polarity of the type and otherwise op¬ 
erates as 

(ei * 62 )^ = ei#e 2 
(ei#e 2 )^ =ei *ei 

5.1.1 Interpretation 

Programs p and q represent blockchain states. For p = 
(ei,... , em){ti', ...; tn}, the e’s represent resources 
available on the blockchain p, while the t’s represent 
transactions in progress. For example, if we write M ■ 
satoshi for satoshi * ... * satoshi, then 

M 

{lhlkchnaddr){txn{lblkchnaddr, M ■ satoshi)} 

represents the genesis block where Iblkchnaddr has 
been assigned M satoshi ’s. At the other end of the 
spectrum, 

{Iblkchnaddr){txnilblkchnaddr, _)} 

represents burning the assets sent to Iblkchnaddr. 


1998. 

[14] Philip Wadler, Propositions as sessions, J. 

Fund. Program. 24 (2014), no. 2-3, 384-418. 

5. APPENDIX: A TERMINATING SCRIPT¬ 
ING LANGUAGE 


At this level of abstraction modeled by the opera¬ 
tional semantics in the next section, addresses are 
more closely aligned with transaction inputs in blockchain 
transactions. Thus, the genesis block is more accu¬ 
rately represented as 


In the main body of the paper we presented what 
amounts to the high level intuitions. In this appendix 
we present enough of the details that a reader skilled 
in the art could implement the proposal to test it 
for themselves. This presentation follows Abramksy’s 
proof expressions from [3] very closely. 


{addri * ... >i= addrut)! 
txn {addri , satosh i); 


txn (addrM, satoshi) 


5,1 Syntax 


P-) Q — (^ 1 ; ■ • • 5 ; in} 

e ■.■.= satoshi ] ... ] ampere 

I ® 

] e * e 
I e#e 
] e —o e 

j choose(a;i,..., a;„){p; g} 

] inl(e) ] inr(e) 

|?e I - 
] e@e 

] \{xi,...,Xn){p} 
t txn(ei, 62) 


programs 
currency units 
address 
isolation 
connection 
obligation 
menu 
selection 
storage, disposal 
contraction 
replication 
transaction 


which for future reference we’ll write genesis. Simi¬ 
larly, the second example is more accurately written 
as 


{addri * ... * acicirM){txn(addri,_);...; txn{addrM,-)} 


we’ll write as burn in the sequel. 

5.2 Operational Semantics 

In what follows we use the notational conventions: 






• e is a list of e’s of length |e|; likewise t is list of 
t’s. 

• txn(e, e') = txn(ei, e'l); ...; txn(en, e'„) assuming 
|e1 = le’l 

• we have operations, ( —)* : Addr — >■ Addr, (— )’^ : 
Addr —>■ Addr snch that given an address x, a;*, 
are distinct from x and each other; these opera¬ 
tions extend uniquely to p, e, and t in the obvious 
manner. 


Transaction 

txn(ei, x); txn(x, 62) —>■ txn(ei, 62) 


Pair 

txn(ei * e'l, e2#e2) ->■ txn(ei, 62); txn(ei, 62) 


Left 

txn(choose(x, x){(e, e){t}; q}, inl(e')) 
—>■ txn(e, e'); t; txn(x, e) 


Right 

txn(choose(x, x){p-, (e, e){t}}, inr(e')) 
—>■ txn(e, e'); t; txn(x, e) 


Read 

txn(!(a;){(e, e){t}}, ?e') —>■ txn(e, e'); txn(a;, e) 


Dispose 

txn(!(x){p},_) —txn(x,_) 


Copy 

txn(!(f){p}, ei@e2) 

—>■ txn(a;, txn(!(x){p}*, ei); txn(!(x){p}'^, 62) 

5.2.1 Interpretation 

The operational semantics shonld be viewed as the 
specihcation of an abstract machine that needs no 
other registers than the program itself. Let’s look at 
an example in some detail. 

Executing a transaction amounts to joining to expres¬ 
sions, ei and 62 in txn(ei,e2). Thus, to send I < M 
satoshi to bddri * ... * bddri, in the context of the gen¬ 
esis block, first we have to turn the genesis block into 
an expression. 


choose{lspndaddr){genes\s; burn} 

Next, we form a spend expression bddri *.. .*bddri ~o 
addri+iHaddvM which will consume / satoshi from 
the genesis block addresses addri through addri, and 
deposit them in addri through addri. 

Now, we can create a transaction that selects the gen¬ 
esis block from the menu of blockchain states via 

txn( 

choose(lspnciaddr){genesis; burn}, 
inl(6ddri * ... * bddri addri+illaddr m) 

) 

Using the operational semantics we see that this re¬ 
duces to 

txn( 

addri * ... * addrm, 

bddri * ... * bddri addri+iHaddrM 

); 

which then reduces to 

txn(addr 1 , bddri ); 

. . . , 

txn {addr I, bddri); 
txn(addr/+i, addri+i); 

. . . , 

txn {addrM, addr m); 
txn(addri, satoshi); 

. . . , 

txn (addrjvf, satosh i); 
which then reduces to 

txn(6ddri, satoshi); 

. . . , 

txn(6ddr/, satoshi); 
txn(addr/+i, satoshi); 

. . . , 

txn {addrM, satosh i); 



This can be seen as a ledger-like representation assign¬ 
ing satoshi’s to addresses. 

Now, the final piece of the puzzle is that that spend 
transaction needs to be created in the context of a 
blockchain state, which constitutes the resulting blockchain 
state. In point of fact, this is a piece of context we 
elided when we formed the transaction to focus on the 
reduction. A more complete picture of the execution 
looks like 


{bddri * ... * bddri * addrj+i * ... * addrM){ 
txn( 

choose(lspndaddr){genesis; burn}, 

\n\{bddri * ... * bddri —« addri+i^addrui) 

) 

} 

* 

{bddri * ... * bddri * addri+i * ... * addrM){ 
txn(6ddri, satoshi); 

txn(6ddr/, satoshi); 
txn(addr7+i, satoshi); 

. . . , 

txn(addrM, satoshi); 

} 

This brings us full circle. At the beginning of the 
paper we explicitly recognized the blockchain as data 
that is program. The reduction above provides an 
explicit model of just this phenomenon. A blockchain 
state, i.e. a representation of data, is a program. The 
transition from one state to the next is the execution of 
the program. Any state of the program actually allows 
a “read back” to a ledger-like representation capturing 
the distribution of resources to addresses. 


5.3 Type assignment 

In the main body of the paper we wrote proof rules 
in terms of sequents. In point of fact, that formalism 
amounts to a typing discipline on the scripting lan¬ 
guage presented above. Here we present the details of 
that typing discipline along with the basic result that 
all well typed programs are terminating. 


Axiom 

h {x : ,x : A){} 


Tensor 

h {t : A,r){txn} h {u : B, A){txn'} 
h (t * M : A 0 B, r, A){txn; txn'} 


Par 

\- {t : A,u : B,r){txn} 
h {t#u : A^ B,r){txn} 


With 

^ hp h g 

p = {t : A,t: G){txn} q = {u : B,u : G){txn'} 
h (choose(x : G){p}{g}) : A&cB,x : G){} 


Left 

\- {t ■. A, V){txn} 
h {inl{t) ■. A + B, r){txn} 

Right 

\- {u : B, V){txn} 
h {inr{u) \ A + B, r){txn} 


Storage Disposal 

h {t ; A,r){txn} h {t : A,T){txn} 

h {?t ■.7A,r){txn} h {_-.?A,r){txn} 


Contraction 

h {t :?A, u :?A, r){ta:n} 

h {t@u :?A,r){txn} 


Replication 

\-p ^ 

p = {t ■. A,t :?G, r){t2;n} 
h (!(T){p} ■■\A,x :?G){} 


Discussion. As is easily seen, this is merely a translit¬ 
eration of Abramsky’s proof expressions from [3] , and 
as such the scripting language enjoys all the proper¬ 
ties of proof expressions. In particular, theorem 7.18 
pg 47 tells us that well typed programs terminate. 

In a discussion of “smart contract” the types play a 
specially important role. If programs in this language 
consitute financial contracts, then the types provide 











a means by which parties can probe the contracts for 
properties above and beyond termination. 



